Team Name

NULL

Client

Dialog Semiconductor

Adviser

Dr. Jingwei Yang


Team Members

Hassan Raza Avatar
Hassan Raza

Developer

Josh Hutton Avatar
Josh Hutton

Developer

Justin Bassett Avatar
Justin Bassett

Developer

Logan Hollmer Avatar
Logan Hollmer

Developer

Quinn Roemer Avatar
Quinn Roemer

Developer

Yunus Kulyyev avatar
Yunus Kulyyev

Developer

Zinadin Keddari avatar
Zinadin Keddari

Developer


Background

Dialog Semiconductor has produced an edge device server called the SmartServerIoT. This device is designed to be used in environments consisting of hundreds to thousands of IoT devices. This hardware must be tested to verify performance and stability while maximizing the number of devices supported at a time.

Scope

The project proposed will interact with the SmartServerIoT by simulating devices and communicating over twisted pair using the LonTalk protocol. The simulator produced will assist in testing the stability of the SmartServerIoT while under high-load. The ultimate goal of this project is to be able to simulate 2,000 devices with a single simulator running on one machine.

Solution

A software simulator that creates and manages thousands of IzoTDevices. This simulator will run on a Linux machine. These simulated devices will directly interact with the SmartServerIoT over LonTalk.

Highlights

In this project, we will be producing a piece of software that interacts with real world hardware. While Dialog Semiconductor already has a simulator capable of performing this task, their existing solution is lacking several key features. Our proposed solution will be capable of simulating a large pool of devices on a Linux machine.


Implementation

We initially set out using C++ to build the project, as we wanted to be able to have enough performance to ensure that we could simulate as many devices as possible. However, midway through the project, we learned that our original design did not work with the client-provided C-based LonTalk framework, which only supports a single device per framework stack and only one stack per process. We carefully planned a re-architecture of our project, settling on a C++ device to interface with the LonTalk framework and a Python runner to orchestrate all the device processes.

We provided a REPL interface to give the user control over the C++ devices which are managed by the Python simulator. The REPL handles creating new devices by starting new processes, as well as any user-requested actions, ranging from temporarily shutting down devices to asking the device process to modify device datapoints or perform network actions. The C++ device handles network communication by delegating the bulk of the work to the LonTalk framework, instead focusing on responding to requests from the Python runner to perform actions and display information.


Lessons Learned

Risk Management
It is risky to depend on the client for tools or test environments. Our client was only able to get us the LonTalk framework and test environment halfway through the project. It was only after fulfilling this client dependency were we able to realize that our design would not work. This late requirement change required heavy workloads on our team, with some team members working over 20 and 40 hours during the sprint to construct a new viable design. Not only did the risky client dependency result in more work for us as a team, but if we had known earlier that our design would not work, we would have had more time to set up better tools and tests for our final product.

Automated Testing
Our original C++ design was set up with automated unit tests and the ability to run automated systems-level tests. The move to our Python redesign happened late enough that we were unable to implement automated tests. This meant that meticulous manual testing had to be reapplied every time we made significant changes, making it harder to add useful features, as every new feature would require a manual retest.

Team Communication
Team communication is invaluable. Our team constantly communicated with each other through messaging applications. Questions about error messages, the code, or ways to implement new features were frequently raised, leading to insightful discussion with other team members who could explain or provide good ideas.

Client Communication
Frequent client communication is invaluable. Earlier in the project, we met with the client on a fortnightly schedule, only occasionally reaching out on Slack for other communication. We came to realize that opening more communication is extremely helpful. By switching to a weekly client meeting, we were better able to give the client a clear view of our status and any thing that we needed help with to navigate their framework and tools.

Finish Tasks Early
It is very helpful to finish sprint tasks early enough to provide adequate time to check for bugs and do some minor refactors. Not only will there be some time to debug any tricky bugs, but the product will be more cohesive because there is some time dedicated to considering the product as a whole each sprint. Furthermore, polishing each sprint before the client meeting makes for a much stronger product demo.

Task Assignment
Some team members preferred to perform tasks as early in the sprint as possible, and some preferred to do so later in the sprint. By assigning tasks that had to be completed early —such as when other tasks depend on these tasks— to the former style of team members, everyone is able to do the work largely unblocked in their preferred style. Additionally, team members have different skills, whether it be writing skills or coding skills. Ensuring that everyone is assigned tasks that they are capable of completing, significantly increases productivity. It doesn't matter if any particular team member would be stronger at another team member's task if the other team member can do that task; it is far more important to spread the work out in a way that each member can actually do the work.


Technologies


  • Python
  • Git
  • C++
  • Visual Studio Code
  • Catch2
  • CMake

Acknowledgements

Special thanks to the team at Dialog Semiconductor that worked with us throughout development. Without their assistance and constant oversight on our progress, development on Mockingbird would have never reached completion.

Special thanks to our professor Dr. Jingwei Yang for his guidance throughout these two semesters and our lab adviser Dr. Ying Jin who provided much needed advice throughout Mockingbird's development, enabling us to keep our end goal constantly in sight.


Timeline